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A Little FileMaker Magic — Three Simple Tricks 


By Mike Harris 

A magician charms us by seeming to violate physi¬ 
cal law, and common sense. Practiced hands and the 
advantage of an audience’s limited vantage point, 
allow the “illusionist” to convince us that something 
remarkable has happened. So, we might say that 
FileMaker magic is the apparent violation of basic 
FileMaker laws, as represented by the official features 
set in the manual, or perhaps simply by what we 
believe we know about the program. 

Once you know the tricks, of course, much of the 
fun of magic is lost. Yet software, including FileMak¬ 
er, is usually shown and taught “trick first” — explain 
a feature then show how to use it. Aside from being 
less amusing, this approach inhibits the creation of 
new magic tricks. The real world comes at you from 
exactly the opposite direction. FileMaker projects 
start with a set of needs and you have to discover the 


right use of features to solve the problems. If you 
only learn “tricks first” — what FileMaker features 
are supposed to do — your imagination is constrained, 
and you are not having enough fun. 

In the last few years I’ve made a lot of presenta¬ 
tions to FileMaker user groups, Claris Solutions 
Alliance (CSA) members and others. I have learned 
that the simplest trick is magical when seen from an 
unusual point of view. I have also learned that no one 
forgets a trick after seeing it do something apparently 
impossible. 

The following articles describe my three favorite 
bits of simple magic. I never get tired of these tricks 

— although I suspect some of my repeat viewers may 

— because they show how little we have really under¬ 
stood FileMaker’s possibilities, and because I love 
the irony that our own worst enemy is what we think 
we already know. 
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Finding the Mayors Husband 




Addresses 


Mr. ] Robert 


Customer 


Dgpresto Vine Merchants 


Unsorted 


' 64j^P^nnuUne 
'Sente Cruz 


CA j95060 


A4y customer phoned and said, “Mike, we 
really love the Customer file you did for us, 
but we have a little problem.” (As a consultant, 
you know you are in trouble now.) 

“Our business is seasonal and part of the 
year we have a couple of temps in the office. 
We are all busy answering the phones, talking 
to customers, so the temps are on their own. 
When a customer calls the first thing we do is 
retrieve their record in your Customer file. 
Problem is, the temps can’t always find the 
right customer record. We are a small, local 
business, so we don’t want to use customer 
codes, or even the last four digits of their phone 
numbers. Whoever answers the phone has to 
find the correct customer record 
based on whatever information 
the customer gives. ” 

All right, I said. Give me an 
example. 

“Our town major’s husband 
is one of our oldest customers. 

He has gotten very upset a couple 
of times when one of us couldn’t 
find his record. His name is 
‘Robert De Angelo’ and accord¬ 
ing to the US Postal Service he 
lives in the city of ‘ Santa Cruz. ’ 

Trouble is, when he calls us he 
most likely says, “Hi, this is Bob 
De Angelo in Bonny Doone,’ 
because he lives in a little town 
the USPS doesn’t recognize. My 
temp tries a Find with ‘Bob’ as 
the first name, a misspelled 
‘Deangelo’ in the last name field 
and another misspelled ‘Bonnie 
Doone’ in the city field.” 

In other words, I said, noting 
to myself that half the population 
of this country doesn’t know the 


city they live in, you want a FileMaker Find to 
work when the request contains three pieces of 
information which are wrong in four different 

ways? 

“Yeah,” my customer said, “I can see these 
problems coming every year but I can’t catch 
them all for everybody who might be answer¬ 
ing the phone.” 

At this point, I might have given the “com¬ 
puters are really dumb and require precision to 
the nearest letter” speech, or perhaps offer to 
show him something about wild card searches 
to help with some situations. 

Instead, I decided to give the customer 
what he wants. His unstated request is to train 


Figure 1 


Figure 2 
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Addresses 


information 


Robert 

Bor, 

Buddy 

Roberto 

Buddie 


De Angelo 

Deangelo 

D'Angelo 

Dangelo 

Dangllo 


HSanta Cruz 
SBonny Doon 

I Bonny Doone 
Boony Doon 
Bonnie Doon 


Associate*;.. T ommy T une 
Buster 


Figure 3 


the database, not the operator. 

Figure 1 shows my customer’s primary 
address layout with the record of the Mayor’s 
husband. The Find request is shown in Figure 
2. Amazingly — nothing up my sleeves — you 
can hit the enter key in this Find request and 
the Browse record in Figure 1 results. 


The trick is done with repeating fields. 

Each field in the Find request is actually a re¬ 
peating field, formatted on the Figure 1 layout 
as non-repeating. On the repeating version of 
the layout, shown in Figure 3, you can enter all 
the different ways the Find request data is rou¬ 
tinely screwed up. Of course, any entry you 
don’t anticipate still stumps 
the Find, but my customer 
was thrilled — it solved his 
problem. 

This works because File¬ 
Maker indexes the contents of 
a repeating field as if the con¬ 
tents of all lines were in the 
same field. Of course, they are 
in the same field. A FileMaker 
repeating field is just a regular 
field formatted oddly. 

-V*- 


Three, Three, Three Forms in One 


A 


clinic treats children with various disabilities. 
Depending on who pays for the care, they need 
to send out one of three billing forms: Medi- 
Cal, MedicAid or Private Pay (when the par¬ 
ents pay). Regardless of where the bill is sent, 
the clinic likes to send a copy of the bill to the 
parents. To get good mailing rates they want to 
mail by ZIP code. This requires that the forms 
be printed in ZIP code order regardless of 
which form is used. They also want the system 
to be idiot-proof. It must always work if the 
correct payer is indicated on the billing record, 
no matter how green the operator. 

The usual rule requiring one layout for each 
form doesn’t work in this case. Of course, you 
can write an elaborate script which moves from 
layout to layout printing one bill at a time. That 


solution is slow to print and possibly a little 
unstable. Here is another way. 

Figure 4 (next page) shows the top parts of 
the three forms used. Figure 5 shows that there 
are only two layouts in this file: one for data 
entry and another to print all forms, regardless 
of type. In Browse mode in the “Forms Print¬ 
ing” layout, you can flip through records and 
each screen displays one of the three forms 
(Figure 6). A close look at the “Payer Type” 
field (Figure 7) shows that each record has the 
form appropriate to the “Payer Type” value. If 
you go to a record and change the “Payer Type”, 
the entire screen for that record magically 
changes into the correct form. 

This trick has two parts. Figure 8 shows the 
“Forms Printing” layout. A single page-size 
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MediCal: 


picture field is behind all the overlapping fields. 
Its contents are looked up from another file 
FormsLU. FormsLU contains three records, 
one for each form. Like paper forms, the pic¬ 
ture of each form has no data, only lines and 
labels. Naturally, the key field matches “Payer 
Type”. So that gets the form right. How about 
the data fields? First Name, for instance has to 
jump around the layout depending on which 
form is in effect! 

The data fields move around because there 
are no real data fields on the “Forms Printing” 
layout. Instead, there are three calculation 
fields for each original data field. The formulas 
for these calculations are such that of the three 
“First Name” fields (one for each form) only 
one calculates to the first name value. The oth¬ 
er two fields calculate to empty and effectively 
disappear from the layout although, ghostlike, 
they are still there. See Figure 9 for the formulas 
of the three “First Name” calc fields and the 
trick is obvious. 

When you try this here’s a tip. Arrange the 
calculation fields for each form on a working 
layout. Test that the fields print out in the 
proper place on each form. Then group all the 
fields for one form and paste the group on the 
“Forms Printing” layout with the field groups 
for the other two forms. If you ever need to 
adjust field locations this saves a lot of grief. 

♦V* 



Michael 
Smith 
Harison 
4149 La Madro 
Santa Oru7 


Figure 5 


The Child ren's Society 

123 Main Steet 

Santa Clara, CA 95060 


(ACCOUNT N3. I ) 


f INVOICE NO. 


^ INVOICE DATE 

J 


B 




1 

L 

L 




T 

0 


PLEASE RETURN THIS PORTION WITH PAYMENT 


DATE 

HOURS 

DESCRIPTION 

RATE 


MedicAid: 


5 BC/BS PROV. NO. 16 FED. TAX NO. I 7 MEDICARE NO.|8 


9 PATIENT'S LAST NAME 


FIRST NAME 

M.l 

10 PATIENTS ADDRESS CITY STATE 

ZIP 

11 BIRTH DATE 

12 SEX 

13 MS 

I ADMISSIONS 

18 A.H. 

19 D. 

L 20 STAT. 

1— 




14 DATE 

1 5 HR. 16 TYPE 1 7 SR 




L 


22 DESCRPT10N 


23 R.CODE 24 £ UNITS 25. TOTAL CHARGES 


Private Pay: 


| DO NOT STAPLE IN BAR AREA 

1 Q MEDI-CAL [" 

2 □ MEDICARE 

PROVIDER NAME AND ADDRESS 


AFFIX IABLE HERE 


PROFESSIONAL/SUPPLIER 
CL AIM FORM , 


AFFIX LABLE HERE 


PATIENTS COMPLETE NAME AND ADDRESS 


MEDICARE NUMBER 


TAR CONTROL NUMBER 


MEDI-CAL I.D. NUMBER DATE 0F BIRTH DATE OF ONSET 

i . i e i, ? i r 1 1 

SEX OTHER COVERAGE 


PATIENT ACCOUNT NUMB ER 

91 — ■ -1 10 l I 11 1 1 12 


LABORATORY NAME AND ADDRESS 


PRIMARY DIAGNOSIS DESCRIPTION 


NAME OF REFERRING PROVIDER 


SECONDARY DIAGNOSIS DESCRIPTION 


SERVICE DESCRIPTION 


Figure 4 
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The Crippled Children's Society 

of SantaClamCounty,Inc. 

2851 Parte Avenue, SantaClara,Ca 95050 

Phtne- 14HR 1 243-788 1 _ 


1 Crippled Children's Society of 
Santa Clara County, Inc. 


Forms fvifc,.]| 1 Crippled Children's Society of 


Records: 

6 

Unsw t.-.: 


±t 


r 


5 BCfBS 


inta Clara County, Inc. 




R*oords : 
6 


{inserted 


f-w- 


DONOTSTAPLE IN BA 


1 Q MEDI-CAL 

2 [xl NED ICARE 


:NI CONTROL NUNBER 

P" 

TYPE 

J0123 


OF BILL 

FED. TAX NO. 

? MEDICARE NO. 


8 

34-1212130 





5 ATIENTS ADDRESS CITY STATE ZIP 
ne San Jose CA 96050 



18 A.H. 

19 D.H. 

20 STAT. 

SRC 





25. TOTAL CHARGES 


125 


Figure 6 


Payor 


S MediCal 
MedicAid 
OPrivate Pay 


Figure 7 



Figure 9 

Name 

lyBi 

Options 

View by 

custom order 

▼ 


* PatAcctNumMC 

Calculation 

= If (Payor = 

"MediCal" ,Pat AcctNum , 

"") 

# 


# RatAcctNumMA 

Calculation 

= If (Payor = 

"Medic Aid " Pat AcctNum 




* Month Birth MA 

Calculation 

= If (Payor = 

"Medic Aid ",Month (BirthDate),"") 



* Day Birth MA 

Calculation 

= If (Payor = 

"Medic Aid" ,Day (BirthDate)," ") 



* Year Birth MA 

Calculation 

= If (Payor = 

"MedicAid" .Right (Year (BirthDate),2).. 



* MediCal X 

Calculation 

= If (Payor = 

"MediCal"/'X"/'") 




* MedicAid X 

Calculation 

= If (Payor = 

"Medic Aid " ."X"."") 



->■ 

♦ FirstNamePP 

Calculation 

= If (Payor = 

"Private Pay ", FirstName,"" ) 


->. 

# FirstNameMA 

Calculation 

= If (Payor = 

"Medic Aid",FirstName,' 

") 


->■ 

♦ FirstNameMC 

Calculation 

= If (Payor = 

"MediCal" pir stName ,"" 

) 
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Through the Looking-Up Glass 


JVIichele is an importer of Japanese antiques 
who wants to do his inventory in FileMaker. As 
each item arrives he plans to create a record for 
it in an inventory file. The record includes a 
“list price”. After an item sells he wants the 
inventory record to reflect who bought the 
item, when it was sold, the invoice number and 
the actual selling price. 

His problem is that the actual selling price 
almost never is the original “list price” because 
in his business the “list price” is usually the 
starting place for bargaining the “real price” to 
the customer. Also, dealers get certain standard 
discounts, some items may get special sale 
prices, and there are discounts for cash pay¬ 
ment or other reasons. The actual selling price 
is only established after the invoice is created, 
and that number can appear on any of the 
different lines of a repeating field in the invoice. 

Figure 10 shows a typical sale in the invoice 
file with item H556 on the repeating field sec¬ 
ond line. The problem here lies in a character¬ 
istic of repeating fields for lookups. Call the file 
into which data is being looked up the ‘current’ 
file (Inventory.FM), and the file from which 


data is pulled the ‘source’ file (Sales.FM). The 
fields that match in both files are the key fields 
(Inv#), which allow transfer of information 
between two ‘data’ fields. When the key (Inv#) 
and data fields (Sales Price) in the source file 
are repeating, FileMaker cannot look up the 
appropriate line of the repeating data field 
(Sales Price) — it always grabs the first line of 
the data field regardless of which repeating line 
the key field matches. So, whatever inventory 
item is matched in the invoice part number 
field (Inv#), the same sales price is returned: 
the first value from the Sales Price field. 

Figure 11 shows that the inventory file 
looks up the wrong price for H556: $960 vs the 
$2,800 it should be. Figure 10 shows where the 
$960 comes from: the first line the Sales Price 
field. 

One way to avoid this problem is to split 
the invoice file into a clone. After the split, 
there are in effect no longer repeating key and 
data fields because each split record contains 
only one entry, located on the first repeating 
line of each field. 

This technique works, even if it is not 



Yatertechnics 

Ray Watts 

64 Penny Lane 


Vatertechnics 

4149 La Madrona Drive 


address 

csz Watsonville 

408 761-3987 


P451 
H556 
B66 


Santa Cruz 


CA 95060 


CA 



desuiptic 


Print actorin green hat 

N eta uk e woman's vanity b ox 

Book book ofinsect prints 


1 , 200.00 

3,500.00 

175.00 


960.00 | 

2,800.00 j 

140.00 | 


Figure 10 
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Inuentry.FM 


Inventory * 

shipment a 


Nets uke 


name 


description 


woman's vanity box 


location 


contemp 


5/3 0/94 


$3500.00 

$1500.00 


retail 


consignment 


requires an inelegant hack for a 
simple, common database need. 
It requires management of the 
clone file. How many records do 
you keep in the clone file? Is it 
current with the main invoice 
file? If not, when do you delete 
“old” records? What happens 
when a full relookup is perform¬ 
ed (possibly by mistake) and 
some records are missing from 
the clone file? If you only use the 
clone file as a temporary reposi¬ 
tory for records for the look up 
of one inventory record at a time, 
won’t inventory updating be very 
slow? What about “corrections” 
to the invoice file? How are re- 


Figure 11 turns handled? (See sidebar on 

elegant. Of course it can be scripted. Still, con- I page eight for details about a split-repeats file.) 
sider the problems of the split records clone A better way to solve the repeating field 

solution. First, it requires a file whose purpose look up problem is to use a tool called “repeat- 

is not obvious to naive users. This can lead to ing field extraction”. This allows you to avoid 

all kinds of screw ups and phone calls for sup- the split-repeats file. Figure 12 shows the in- 

Figure 12 P ort - Il: makes FileMaker look bad because it ventory record for the item (H556) which 



Inuentry.FM 


PriceExtract = If (Extend (Invt Number) = InvNurnLU.Selling PriceLU,"") Number • 20 repeats 
Sold Price True = TextToNum (Last (PrieeExtraot)) Number • no repeats 


5/30/94 


sold price true 
$2800.00 


InvftunLU Selling PriceLU 

PriceExtracI 


P451 

960 



H556 

2800 

2800 


B66 

140 




appeared on line 2 of the invoice 
file. The trick is to look up from 
Sales.FM both the Inv# and 
Sales Price fields, with all their 
repeat values. Then, with a calcu¬ 
lation, the correct “sold price” is 
extracted from the Sales Price 
repeating field into another 
repeating field. This value is 
brought into a non-repeating 
field using the Max or Last cal¬ 
culation. The result is “Sold Price 
True” thanks to a little sleight-of- 
hand to cover a limitation of 
repeating fields. 

Finis 

Of course, these bits of File¬ 
Maker magic make a very serious 
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point: whether you limit your imagination by 
what you know about computers (Trick 1), by 
the obviously right way to use FileMaker (Trick 
2), or by the official features list (Trick 3), the 
result is episodes of frustration and boring 
predictability. Weird problems are the Fairy 


Godmother of FileMaker magic. Treasure 
them. 

A diskette of templates illustrating the three 
magic tricks and other articles in this issue is avail¬ 
able from the newsletter office. The price is $18 
plus $4 S/H. Ask for part number FMR64. 


Splitting Repeating Fields 

T he split record technique, or kludge if you are inclined to be harsh, was the first and most basic attempt to 
deal with the limitations of repeating fields. It was invented by S.C. (Kim) Hunter, who introduced it in his 
FileMaker utility, MakeRecords®, and discussed it in these pages. Later, Kim’s trick was built into FileMaker 
and you can read about splitting repeating fields into records in pp 8.8 to 8.10 of the FileMaker manual. The 
original problem that splitting records addressed was the task of counting items in invoices that used repeat¬ 
ing fields for items sold. There was no obvious way to do this without record splitting. 

Splitting repeating fields into records requires a clone of the original file. Starting empty, the clone file is 
filled by importing one or more records from the original file. Unlike a regular import of records from one 
file to another, more than one record is created in the clone for each record imported—a new record is 
created for each repeating field entry in each original record. The result is a set of clone file records in which 
the repeating fields have only a single entry in each record. This in effect collapses the repeating fields into 
non-repeating fields. No repeating fields means no repeating field problems, sort of a Joseph Stalin style 
solution. 


Original Invoice File 
(1 record, 3 repeating line items) 


Split Clone File 
(3 records, 1 repeating item each) 


P451. 

.$960 

Import & Split 






H556. 

. $2800 




B66. 

.$140 


P451. 

.$960 




Inventory File Inventory File 

Lookup based on Part Num does not work. Lookup based on Part Num does work. 
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Scripting to the Next Available Repeating Line 

By Mike Harris with the screen nearly horizontal. This means 

special cabinetry and possibly serious cooling 

I 

We are trying to create a FileMaker point problems. Consider using a large programma- 

of sale (POS) system. It is for a photo develop- ble key pad instead. They look like the tops of 

ment store with a limited number of products McDonald’s cash registers and are available for 

(currently ten). The stores are operated by a both Mac and Windows. Some types have 

single part-time employee so the station needs surfaces which are completely programmable 

to be idiot-proof We are considering using a and others come with a fixed grid of program- 

touch screen and having a set of buttons on- mable buttons. The commercial versions are 

screen corresponding to each of the ten prod- only available for Windows. However, any 

ucts. We would also include a simple on-screen Windows keyboard device can be attached to 
number key pad and a few other buttons like the Mac using a converter box. The key pad 

“new invoice”. We want to use no keyboard or solution is more flexible and less expensive, 

mouse. It all seems fairly straightforward ex- Getting button scripts to go to the first 

cept the use of repeating fields for the invoice available line on an invoice can be done a 

line items. Since the item buttons might be couple of ways. One is to use an “add-on stack”, 

pressed in any order, we don’t know how to described in issue #35 and in an Application 

make the button scripts go to the first available Note (“Ins & Outs of Repeating Fields”) avail¬ 
line. Any ideas? able from The FileMaker Annex. Briefly, an 

add-on stack temporarily stores new informa- 
!A Several. First, having done several POS tion in one or more non-repeating fields. The 

systems, I suggest you reconsider the touch information is then looked up (a self-self-look- 

screens. To keep operators from getting shoul- up: same file, same record) into the first avail- 

der cramps and headaches, the monitor has to able repeating field line. This lookup scheme 

be mounted at a very odd angle (for a monitor) works using calculated match codes which 
Figure 1 allow FileMaker to place the 

new information properly in the 
first available line. Figure 1 
shows a schematic representa¬ 
tion of the trick. The “New 
Entry” fields contain the next 
items to be added to the repeat¬ 
ing fields. 

The add-on stack may be 
your best bet. It depends on 
exactly how the file is used, 
performance and other consid¬ 
erations. Since add-on stacks 
have been thoroughly consid¬ 
ered in a previous issue, I will 
describe another scheme which 
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may be preferable in some situations. 

You can use the script step “Go to Lay¬ 
out... layout number given by field...” to get to 
the right repeating field line. Here is how to do 
it. First, a new item button script needs to know 
how many lines in the current invoice are 
already filled. This is done with a simple calcu¬ 
lation based on the Count function for repeat¬ 
ing fields. Count looks at a repeating field and 
says how many of the repeating lines contain 
some value. J 

Lines Filled = {numeric result} 

Count (item description) 

| 

where “item description” is a repeating field 
Now you need a copy of your invoice lay¬ 
out for each line of the line items repeating 
field. Name the original invoice layout some¬ 
thing like “Invoice Line 1”, the second “Invoice 
Line 2” and so forth. For each layout set a dif¬ 
ferent tab order. “Invoice Line 1 ” must start the 
tab sequence in the first line, probably in some¬ 
thing like an Item# field. Presumably this is a 
key field for looking up Item Description and 
Price. You probably need a second tab to a 
Quantity field — you can use as many tabs as 
you like. Then, in the “Invoice Line 2” layout, 
set the tab order to start with line 2 of the re¬ 
peating fields. Continue through 


This step looks at the value in a field, then goes 
to the layout which corresponds to that num¬ 
ber. FileMaker considers the existing layout 
order to determine which layout is, say, num¬ 
ber three: it is the third layout appearing in the 
layout menu (see Figure 2). Assume that the 
first layout is the main menu screen with the 
operator’s POS buttons. If the second layout is 
“Invoice Line 1 ” and all other invoice layouts 
follow, then we need a new calculation based 
on the “Lines Filled” calculation to guide this 
key script step. Suppose that we have already 
entered two line items. We want to go to the 
layout “Invoice line 3”, which is layout number 
4. So: 

Layout Destination = {numeric result} 

Lines Filled + 2 

After the script moves us to the proper 
layout a simple “Go To Next Field” step with 
no field specified moves the cursor to the first 
field in the tab order, which of course is in the 
first available repeating field line. Figure 3 shows 
a typical final script for one of the item buttons. 

Using layout navigation as a way to make 
FileMaker smarter is a powerful tool. Michael 
Singer’s book (see review in Issue #63) discuss¬ 
es this technique extensively. In an upcoming 


all the invoice layouts. It may 
seem that this is a wasteful way to 
use file space. However, extra 
layouts are actually a very frugal 
way to “program” FileMaker, 
often much better than using 
calculations to get the same re¬ 
sults. Besides, we are not wasting 
file space, we are using it to ac¬ 
complish a task. 

You can now write button 
scripts which automatically go to 
the first available line. The key 
script step is “Go to Layout... 
layout number given by field... 
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Figure 3 


Script Definition for “55 MM, 56 slides” 


Available Steps 


Perform Script [...] 
Pause/Resume Script 


Go to Layout [...] 

Go to Record/Request [...] 

Go to Next Record/Request [...] 
Go to Previous Record/Request 



_ "55 MM, 56 slides'*' 

♦ Enter Browse Mode [] 

♦ Go to Layout [Refresh, "Layout Destination"] 

♦ Go to Next Field 

♦ Select All 

♦ Paste Literal ["55.56S"] 

♦ Go to Layout ["Main Menu"] 


article, 1 will show how to use tab order and 
layout variations to achieve some really re¬ 
markable results. 


The FileMaker Annex carries the hardware 
and software components needed to construct a 
FileMaker POS system. A catalog is available by 
calling 408-761-3987. 


A Big White Box for the Page Break Blues 

Printing Variable Length Multi-Page Text Fields 


By Roger Grodin and Mike Harris 

In issue #53 an article on a template for writing 
a police crime report considered the problem 
of printing a multi-page text field. In that case, 
the text field was used for the “narrative” part 
of a crime report. In the narrative the officer 
writes about anything which does not easily fit 
into the standard crime report form boxes. 
Since this narrative can be almost any length, 
the narrative text field stretched across several 
page breaks. The author of that article showed 
how to use increased line separation and care¬ 
ful field placement to reduce the risk of bad 


Figure 1 


an unexpected the head and in frontal attac 
this point is therefore another method for 
problem for an unexpected the head and in i 
character of. This point is therefore anoth 
.fl.up.r..t.n.l.d...t.he..nrntxlP.m...fnr..an..i.in eYne.c.t.p.d....T.I: 




l .. Uf .Y. a £ > Y....'.^yy'cy^«i*i'<y”pY*xyurru’YYY**Y*v;Y***'cyi’r*'cvri'U'i*tip'V)X)'wxar:*** 

writer that the character of this point is 
the time of who ever told the problem foi 
on. An English writer that the character 

thP lpttprc that thp timp nf whn Fwpr tn 


page breaks — particularly the cutting apart of a 
line of text and printing the top half of the 
letters on one page and the bottom half of the 
line on the following page. See Figure 1. 

Still, that solution is not consistent. From 
time to time, particularly if the writer uses an 
unanticipated line format somewhere, the 
problem still occurs. 

There have been a number of attempts to 
solve this problem by counting lines. File¬ 
Maker cannot count lines directly, so this ap¬ 
proach counts characters and tries to translate 
that into the probable number of lines. Then a 
set of calculation fields distributes text on a 
page-by-page basis, one calculation field per 
page. This solution requires an extra calcula¬ 
tion field per page which raises storage require¬ 
ments and slows performance. Also, except in a 
few very structured circumstances, this solu¬ 
tion doesn’t work consistently either. 

Most of the time the least worst way to 
handle multiple page text is to simply create 
separate text fields for each potential page and 
move your text from field to field (page to 
page) as required. Looking at a preview of the 
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document before printing allows final adjust¬ 
ments by cutting and pasting snippets of text 
from one field to another. This solution has a 
host of cranky little inconveniences like the 
need for multi-page sliding and/or multiple 
layouts. Also, all the text is not in a single field 
which makes finding awkward. 

This article describes another approach. It 
is also not perfect but it is largely automatic, 
leaves all text in a single field and, for a given 
page set up, font and printer, never fails . The 
trick is entirely layout-based so no new calcu¬ 
lations are required. Figure 2 shows an edge-on 
side view of the layout layers used. Only two 
new layout objects are required for each addi¬ 
tional page of text beyond page one: a copy of 
the text field and a large white box layout object. 

By layering these objects properly and 
spacing them to the nearest pixel, the first page 
prints a certain number of lines (42 in our 
example) and the second page starts with the 
next line (43) every time. FileMaker text fields 
do not cut lines in half except where they cross 
page boundaries. Instead, if a line of characters 
cannot be fully printed it is left off altogether. 

In the area where a text field (see Figure 2, 
“Text Field, Second Copy”) does cross a page 
boundary it is not used for printing but is cov¬ 
ered up by a white box in the layer above. 

The Recipe 

Many readers can recreate this trick based 


on Figure 2, but it takes a while to work out the 
placement subtleties. So, here is a tested recipe: 

1. Select the printer or fax modem to be 
used with this document. Now redo the Page 
Setup. This is very important. 

2. Create your layout to be used for print¬ 
ing and stretch the body part to cover the max¬ 
imum number of pages required. Here we 
assume two pages. 

3. Put your text field on layout page 1 only, 
sized and formatted as you like for single page 
output. Put a copy of this text field on top of 
the first one, but placed approximately two 
inches lower down the page. Make sure this 
copy is formatted exactly the same as the first 
version of the field. 

4. Now, here’s the key for placement: using 
the dotted base lines visible in layout mode, 
count the exact number of lines on the first page 
(42 lines in our example). Write this number 
(called “Linesl”) down for use a couple of 
steps later. Align your two text field’s left and 
right edges. 

5. Extend the bottom of the second (the 
copy) text field to near the bottom of page 2. 

6. Now we need to create a temporary tool 
for layout spacing. Create an empty box (out¬ 
line only) at the top of the layout with the rect¬ 
angle tool. Make this box wider than your text 
fields, but the exact length of the difference 
between the top of the body of the first page 
(don’t include the header if you are using one) 


Page-to-Page Gap 

Text Field, First Copy 


Figure 2 


* numbers refer to the lines of text 


42* 


White Box 
42 43 


Text Field, Second Copy_ 85 
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Top of Page 2 Body 
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and the first text baseline of your page one text 
field (usually 1-2 inches). This “spacer box” 
allows you to quickly get pixel perfect layout 
alignment. 

7. Move the spacer box down the layout 
and align (overlap) the top edge of the box 
with the page two page break (a dashed line). 
Now overlap the text baseline of the second 
text field’s “Lines 1” + 1 (line 43 in our example) 
line with the bottom edge of the “spacer box”. 

You may find it helpful to create a tempo¬ 
rary text object that is a vertical, return delin¬ 
eated column of numbers, “Linesl” + 1 lines 
long, formatted with the same font and line 
spacing as your text field, to aid in this align¬ 
ment. It also helps to reduce the layout magni¬ 
fication from 100% to 50%. When you are 
within 10 or 12 pixels of alignment, try going 
back to 100% magnification and using the 
arrow key to move the text field one pixel at a 
time. This may keep you from loosing track of 
your target base line. 

8. Go back to the top of the layout and 
create a big white box that is filled with white 
and has a white border. Make it wider and 
taller than your text fields. Drag the bottom 
edge of the big white box to align exactly with 
the text base line one line above the bottom of 
outline box (bottom of the “Linesl ” line on 
2nd text field, line 42 our example). This just 
covers the text line which is the last text line 
printed on page one. 

9. Select the big white box and use the Send 
to Back command under the Arrange menu to 
place the big white box underneath the other 
layout objects. Then do the same to the second 
(longer and lower) text field. These two steps 
result in the layering shown in Figure 2. 

10. Delete the temporary outline box and, 
if you used one, the temporary vertical text line 
counter. 

You can repeat these steps for additional 
pages, layering additional properly positioned 
and stretched text fields and white boxes under¬ 


neath existing objects. 

There seems to be no simple way to auto¬ 
matically avoid printing all the pages on a given 
layout, even when all pages are not required. 
This is because FileMaker feels obliged to print 
the white boxes, even though they are invisible 
to us. Making the white box non-printing just 
defeats its function of covering the top part of 
the second text field. Trying to slide objects 
also messes up the trick. If you are printing one 
record at a time, it is not too much trouble to 
preview the record and use the print dialog to 
print only the pages containing text (the Print 
Pages ...thru.... option). 

To automatically avoid printing extra pages, 
AppleEvents or QuicKeys can provide an effec¬ 
tive solution. Another possibility is to use mul¬ 
tiple print layouts: a single page layout, with 
one additional layout for each additional page. 
A check box, radio button or controlled calcu¬ 
lation field, much like the “number of pages” 
field, could direct a printing script to the cor¬ 
rect print layout based on a field value using 
the “Go to Layout.. .layout number given by 
field.step. (See Q&A this issue for another 
example of this technique.) 

If done correctly, headers and footers will 
print perfectly. Your text will never break at 
page boundaries again, and neither will Claris’ 
Tech Info faxes, as long as you (and Claris) 
remember to set this whole series up after you’ve 
chosen your printer and page setup. If you use 
different printers, or a fax modem, you need 
separate layouts for each one in which the page 
breaks and/or widths do not coincide. . 

Roger E. Grodin is a FileMaker consultant in 
Southern California. He invented the Big White 
Box trick and has used it often for clients in law, 
medicine, and real estate. One of his favorite uses 
is for jury instructions. Roger can be reached at 
AOL: Redwing. A simple example file for this 
article is available on the template disk for this 
issue. Ask for item FMR #64. 
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Hello! 


By Mike Harris 

Editor of The FileMaker Report 

With this issue of The FileMaker Report 
I am the new Editor/Publisher. Your host until 
now has been Joe Kroeger, who started the 
newsletter, nurtured it in the early years, and 
guided it into adulthood. 

The first time I saw a copy of The FileMaker 
Report was in the office of a client. I had been 
doing FileMaker consulting for a couple of 
years and thought I was a pretty clever fellow. I 
was getting the job done for my customers and 
they were quite happy with the results. 

A quick look at The FileMaker Report, 
however, was a humbling revelation. Inside 
this somewhat plain little tan newsletter was a 
world of FileMaker wizardry I could never 
have imagined. While the specific tricks were 
useful and marvelous, the meta-value of the 
articles was to show what was possible with 
FileMaker once your imagination was freed 
from the feature set. 

This is what Joe accomplished in his 63 
issues — a continuing redefinition of what is 
possible, ongoing proof that when you say 
“FileMaker can’t do that” you are almost 
certainly wrong. Joe is the one who invented 
the phrase “If it can’t be done with FileMaker 
it’s not worth doing!” I can assure readers that 
FileMaker Magic will continue to be our 
uncompromised main mission. 

(For those who have not met him, I man¬ 
aged to sneak a squinty picture of Joe into this 
issue — see Figure 3 on page 3.) 

In the last couple of years, due to the press¬ 
ing demands of consulting work, I have written 
less than I should for the newsletter. The result 
is a two or three year backlog of “good stuff’. I 
look forward to getting caught up, to sharing 
with readers what we’ve learned doing some 


very interesting projects. At the same time, I 
want to open the these pages to a larger group 
of writers. It is clear from the size of the current 
Claris Solutions Alliance (CSA) that there is a 
lot of interesting new FileMaker work out there. 
I would like to hear some article ideas from 
those who have never written here before, from 
those who may have never written for any news¬ 
letter before. There are also some new areas for 
the newsletter, like training issues, that I want 
to cover. Since many readers are consultants or 
in-house guru equivalents, we need some cov¬ 
erage for them. I’d also like to revive the File¬ 
Maker Challenge. Readers come up with a 
remarkable array of tricks when a problem 
interests them. 

Every newsletter reflects the personality of 
the editor, even when an editor strives for pro¬ 
fessional distance. I have strong opinions, as do 
several of the more established pillars (maybe 
that should read prima donnas ) of the File¬ 
Maker community, and I see no particular 
reason to downplay controversy. After all, our 
readers can decide for themselves where to 
assign credibility. In the last issue, I wrote a 
review of Michael Singer’s book Database 
Design in FileMaker Pro*. Rich Coulombre, 
coauthor of FileMaker Pro 2. Ofor Macintosh, 
published by Addison Wesley, felt I slighted his 
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book. Rich has a legit beef, so we will be pub¬ 
lishing soon his note and my reply along with a 
review of his book. Expect to see this sort of 
interchange in future issues. I believe readers 
deserve to hear what our writers really think— 
those things they may say to each other over 
drinks at a computer conference but seldom 
publish. 

I sometimes feel a little silly about my still 
intemperate enthusiasm for FileMaker — after 


ten years! After all, it is database software used, 
as often as not, for the mundane business of 
keeping business records. Yet FileMaker is 
special, in the way that the very best is always 
special, whether it is a wonderful Japanese 
kimono, an exquisite rose, or a delicious fudge 
brownie. Expect to see many more issues of 
great FileMaker magic. 

* which unfortunately listed the wrong publisher; the 
book is published by Wiley. 


Moving On 


By Joe Kroeger 

is venerable newsletter has been sold to 
Michael Harris and is no longer being pub¬ 
lished by Elk Horn Publishing. Starting with 
this issue Mike becomes the editor and pub¬ 
lisher. I’m leaving you in good hands — you 
will find Mike’s idea’s and energy to be fresh, 
interesting, productive and valuable. 

I published the first issue of The FileMaker 
Report in January, 1987. That is a long, long 
time ago. In the early days I supported the 
newsletter by taking outside work. It took years 
before the Report could stand alone and even 
then it was more a labor of love that a money 
maker. 

I liked FileMaker, even back then, but I 
could not have predicted how wonderfully 
successful it would become. Two software 
publishers later, FileMaker is a Claris product. 

I have disagreed with Claris on a few issues 
over the years, but they have done a brilliant (if 
sometimes slow) job at defining and imple¬ 
menting new features that have generally kept 
FileMaker efficient and quite capable. Pro 3.0 
promises more great stuff. 

It is time now in my life to change course — 
to back away from the daily grind of writing 


and editing and publishing. I’m ready to tackle 
some of the projects and books I’ve put off for 
the last decade. I remain enthusiastic, as always, 
about FileMaker and I will continue to write 
occasional articles for the Report. 

I am moved to make these radical changes 
by the death of Louise, the love of my life for 
the last 15 years. She will be greatly missed as 
she was loved by many friends. 

Louise was Protector of the Cash Flow here 
at Elk Horn Publishing and ran the office and 
the production. Many of you had opportuni¬ 
ties to speak with her on the phone. She was 
great for the newsletter and wonderful for me. I 
can’t think of continuing The FileMaker Report 
without her. 

I have few regrets; one is that we actually 
printed fewer issues than I hoped to. (On the 
other hand, we worked hard to bring you a 
very high average level of article quality.) 

Many thanks to those subscribers who 
have supported the newsletter over the years 
and to those who have written to express ap¬ 
preciation for the content and the style. Re¬ 
member always to relish FileMaker. 

The newsletter has been for me sometimes 
frustrating, but also often fun and gratifying. 

Goodnight dear sweet Louise. 
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FileMaker Version History 

Version 

Release Date 

FileMaker Pro 2.1 v3 

July 1994 

FileMaker Pro 2.1 v2 

February 1994 

FileMaker Pro 2.1 vl 

August 1993 

FileMaker Pro 2.0 v4 

April 1993 

FileMaker Pro 2.0 v3 

February 1993 

FileMaker Pro 2.0 v2 

November 1992 

FileMaker Pro 2.0 vl 

October 1992 

FileMaker Pro 1.0 v3 

March 1992 

FileMaker Pro 1.0 vl 

October 1990 

FileMaker 4 & FileMaker II 

July-October 1988 

FileMaker Plus 

August 1986 

FileMaker 1.0 

May 1985 


Minor revisions before FileMaker Pro are not listed. 

About Claris 


Claris Corporation publishes the FileMaker program. The 
generic address for Claris is: 

Claris Corporation 
PO Box 58168 
Santa Clara, CA 95052 

Add these mail stops to the generic address as appropriate. 

Customer Assistance: M/S C-11 
Technical Assistance: M/S C-12 
Software Registration: M/S C-71 



The general Claris phone number is 408-987-7000. 
Claris Customer Assistance is 800-325-2747. 

Claris Support recorded help line is 800-735-7393. 

Claris Support Fax line is 800-800-8954. 

Claris BBS is 408-987-7421 (settings 8/N/l). 

Claris Technical Assistance (Mac) is 408-727-9054. 
Claris Technical Assistance (Windows) is 408-727-9004. 

Technical Assistance hours (Pacific Time) are 6 am to 
6 pm Monday - Thursday and 6 am to 2 pm Friday. 
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